IBIS Macromodel Task Group Meeting date: 02 August 2016 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM * Luis Armenta Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Radek noted that he had prepared a presentation for discussion. It was motivated by last week's ATM discussions, specifically the statement that we do not need [Pin Reference] and the tabling of the I/O Reference Terminal discussions. - Mike LaBonte noted that he had prepared the list of potential BIRDs for 6.2. ------------- Review of ARs: - Ambrish to check for collaborators' feedback on his nearly ready new version of the Backchannel proposal. - In progress. Ambrish said that he expects to have something ready to go on the agenda in the next few weeks. - Mike L. to prepare a list of IBIS 6.2 BIRD Candidates. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Two sets of minutes needed review, as the July 19th minutes were not prepared and posted in time for the July 26th meeting. - July 19th minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Radek: Second. - Arpad: Anyone opposed? [none] - July 26th minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Curtis: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: List of IBIS BIRD Candidates from the Editorial Task Group: - Mike LaBonte: [sharing IBIS 6.2 BIRD Candidates rev1] - This document starts with the top two lines of the current BIRDs webpage and has new potential candidate BIRDs added as A through M. - Many may be coming to ATM because they have technical content. - Arpad: Do we have authors, etc., for them? - Mike: No, we need authors. - Bob has offered to work on K. - Bob: D likely gets folded into BIRD 180. - Mike: D, E, and F are likely coming to ATM. - J may also. We likely agree on it broadly, but some subtleties may need to be discussed. - Bob: L is a cleanup proposal by Michael Mirmak. - Radek: The only thing I don't see in this list is the DUT_ref_terminal. - F is [Pin Reference], but there was also a DUT_ref_terminal proposal. - Walter: I think those were competing proposals. - One was Pin based and one was bus_label based - The explanation for having two is related to Radek's proposals. - Walter: I think B will require a BIRD. - A is editorial in my opinion. - C is introducing the concept of a "signal" or "local" ground. I don't think that is editorial. - Mike: The idea is that all of these would be BIRDs. Not all have technical content that requires review in ATM or another subgroup. - Walter: For those not in the Editorial meetings, I want to mention that I came up with a draft IBIS 6.2 that incorporates what I believe is the latest thinking on all of these proposals. - All of these have been written in some form or another. - The idea was to get the ATM group, which may have a larger more diverse set of attendees, to take over some of them. There's a lot of detailed work involved in getting a BIRD written up correctly. - Arpad: Can you post this? - Mike: I will post this document since we showed it here today. - It is shared with (already posted to) the Editorial Task Group archives. Radek's IBIS Ground Issues presentation: - Radek: [sharing: Alternatives in IBIS Ground Issues] - Last week's private email discussions led to a statement that the [Pin Reference] proposal was no longer needed. Then that topic was tabled in last week's ATM meeting. That prompted me to prepare a few slides to summarize my view on the topic. I presented them at the Editorial meeting, and it was suggested that we discuss it in here the ATM. I've added some text to create this presentation. - [slide 2: Legacy IBIS] - Buffer, package model, channel/load. - W_Element5 in the figure represents an IBIS package model in general, it is not meant to imply w-element only. - Board connections, power supplies, etc., indicated in upper box next to the IBIS file box. - Ref rail represented 0V in DUT, but not necessarily in simulation. - "GND" was a better notation than the ground symbol. - "GND" was first [in the [Voltage Range] days]. Separation of the pu, pd pc, gc terminals came later. Originally, pd and gc coincided with the ref or "GND" terminal and both were the same. - What's important is that ref or "GND" was considered the reference node for the signal I/O that goes to the outside world. - The goal of this picture is to show the pins connected to the buffer rail terminals were not necessarily the same as that ref or "GND". They could be the same but not necessarily. - Discussion: Arpad and Radek noted that even a legacy per pin RLC package model would follow this picture, as the C had to go to a reference. Walter said the picture was a fair representation of what IBIS 6.1 says. Walter noted that in the [Voltage Range] only days, the implied "GND" ref would have been included in the package. It was when the separate rail terminals were added that IBIS had been a bit sloppy and left open the possibility of this picture. Walter noted that he understood the point that Radek was making with the picture, but he said that once you show a "channel" (as opposed to a "load" during DUT), the return current path would have to be part of any valid package model. Radek agreed that the return path would have to be part of a valid package. He noted that the picture was drawn to show that this ref did have to be part of the package, but that the "GND" implied ref was not really part of the IBIS description itself. IBIS does not describe the what pin in the [Component] serves as the reference for a specific buffer. Walter noted that we want to distinguish between two concepts of reference. One is the location from which you make relative voltage measurements, and the other is where the return path currents are. - [slide 3: Legacy IBIS "GND" Issues] - Identification of the reference terminal for the output signal is essential. - Legacy approach just considered GND as the reference. - C_comp, R/L/C type package models, and [Define Package Model] are all defined implicitly with respect to GND. - Both types of package models contain capacitance values that will lead to inconsistent simulation results if not connected properly. - [slide 4: Legacy IBIS - coinciding rails] - Case A [from slide 2] is a superset case where all the [* Reference] values were different. - We may have fewer separate rails if [* Reference] values are the same. - A1 is the special case where [Pulldown Reference] is zero, and all other [* Reference] values are different from zero and each other. - The GND rail coincides with the pd_ref. - We have the same concept here of the output port's reference terminal. - This case of the reference node for the signal (GND) now coinciding with the pd_ref seems to be acceptable to everyone. - Discussion: Walter noted that he thought the A1 figure should include a fourth node in the supply box and a vertical line from it to the ref line. Radek agreed. - [slide 5: Legacy IBIS - what's missing] - A1 figure is not controversial. - It may be useful to expand this idea. Perhaps it would make sense to allow the ref to correspond to a rail with a non-zero [* Reference] value. - For example VCC in PECL. - One of the DUT_ref_terminal proposals exploited this idea. - When all of the [* Reference] values are non-zero we have a clear ambiguity. - For any simulation, power-aware or not, we should be very clear about how the signal I/O port (the pair of the I/O terminal and the reference terminal) is defined. We want to clarify this. - [slide 6: Preferred Solution] - Figure B - A Pin on the Component provides the reference node. - [Pin Reference] keyword proposal could facilitate this and allow the model maker to specify it. - This figure, or trivial simplifications of it (collapsing common rails), could cover 99 percent of cases. - Proper handling of the collapsing of common rails could be provided with the DUT_ref_terminal proposal, or by extending the referencing constructs to include a [GND Reference]. - [Pin Reference] proposal has value. I was surprised last week when it was announced that we don't need it. - Walter: This figure B is the proper legal picture. - It handles RS-232 (e.g., +12V and -12V rails), and it handles PECL. - The only thing it doesn't handle is some split PECL where you don't have the 0v reference as a pin on the chip. - For 99+% of cases this figure is sufficient. - What is the need for identifying which Pin is that reference pin? - If the model maker knows what that pin is, they can make their package model accordingly without having the [Pin Reference] keyword. - Radek: We have to think about that. - But even if you don't have a full package model, just RLC per pin, you still need a reference for the C. We can't neglect it. - Arpad: I have a question based our earlier IEEE P370 discussion. - We talked about daisy chaining s-parameter blocks and the need for the reference terminals of connected ports to be the same. - Given that is true. If you have a reference terminal in this package in the IBIS file and we connect to an outside s-parameter model, how can we determine what that common reference is if we don't define the reference in this IBIS file? - Walter: That question is confusing the two kinds of references. - The return path may not be the same as the voltage reference terminal. - For example, in figure B if the return path from the I/O signal is going to the power clamp rail then the s-parameter blocks have to be between 3 and 2 both inside the package model and outside on the board. - That will be known from the documentation that comes with the part. - Your question is talking about the return path terminal. - Arpad: If you look at the W element drawing (figure B). - You have 5 output ports, and each one uses the ref as its negative terminal. - If there's another w-element or s-parameter model outside the IBIS box for PDN or signaling, wouldn't that model have to have the same referencing arrangement as the box in the IBIS file? - Radek: That's the case we started talking about last time. - What you said is valid to some extent, but we have to make things very clear to the model maker and the user. - [returning to slide 6] - There's an important usability aspect to providing this reference node directly to the user. In the rare case of 4 independent rails, the model maker or user could take advantage of 4 independent non-zero sources defined with respect to that node to supply the four rails. - [slide 7: Floating Buffer - do we really want this?] - Forget about the "ref" label in this picture. It is no longer the same as in previous pictures. - We still have the package and its five terminals on the board side. - The actual reference terminal for the outside world/channel now has nothing to do with the terminals in the package model. All the definition of this reference terminal is 100% outside of IBIS in this case. - This set up is 100% up to the user, and we wouldn't give the user the ability to verify the v(t) data in this case. - This is even possible with a legacy model. We could have a per pin RLC model with no C. We could have [Package Model] matrices such that the location of the local ground for the measurement makes it irrelevant for the package data. - But if we want to support this case we need to state things very clearly. - Walter: This picture is excellent. - This is the case of the MECL part where VCC is +2V and VEE is -2V and there is no GND pin on the package. - This is fine if you use what Scott McMorrow refers to ground-based power- aware modeling where there is a GND every place in the system that is ideal and connected to node 0. - We have to say: - This particular case is very rare. - You can't do power aware simulations where the GND is floating. All return paths go through node 0. - For this type of component, you have these limitations on a power aware simulation. - For the other cases, where the rails collapse, EDA tools know what to do. - Bob: I disagree. I think we can support this case already. - There may be a caveat about power aware simulations, but I think a generalized power aware network can support it. - Arpad: Thank you all for joining. ------------- Next meeting: 09 August 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives